Patrick Elliott <sha### [at] hotmailcom> wrote:
> Ok.. The key word here is *DATA*. I was not aware that the #read 
> directive was intentionally design to also execute code if found.

  I don't know if the #read command was *intentionally* made so that
it can also interpret SDL script. However, this side-effect is useful.

  I should specify more clearly what #read does. What I said earlier
may be understood wrongly.
  #read expects to find floats literals, vectors (containing literals)
and strings in the input file. The data it will read into the given
identifier needs to be a literal.
  However, if while searching for such literal it finds a #-command
(such as #declare) the parsing engine will interpret that.

  That is, suppose you have this in your data file:

1,
#declare Var = 5;
2

  When you read one item with #read, then '1' will be assigned to the
identifier given to #read and that's it. However, after you read the
next item, '2' will be assigned to the given identifier, but as a
"side-effect" the identifier 'Var' will have the value 5.

  This is actually extremely useful. We have used this feature in
the new PCM file format supporting uv-coordinates and textures:
The PCM file can have a declared array containing the textures and
thanks to this property the textures can be used in the PCM macros.

  Removing this feature would be a major drawback for the format.

  I agree, however, that #read is a bit inconsistent on how it
handles certain things in the input.
  For example if you have this in your input file:

1+2, 3+4

then #read will not read the values '3' and '7', nor will it issue
an error message.
  This might be something to develop further to either direction.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message